The present invention relates to a method and apparatus for synthesizing and analyzing circuits and, more particularly, to a system and method for specifying, synthesizing, analyzing, and simulating synchronous digital circuits for frame protocols.
Today's digital hardware systems are highly complex, layered, and operate at many levels of abstraction. Tomorrow's systems will be even more complex. As a means of addressing the design of systems whose complexity is continually growing, designers are moving to higher levels of abstraction.
For designers, especially telecommunication designers, the term "frame" is often used to describe a structured data format such as a packet, header, or cell. Frames are a medium familiar to designers for describing structured data and are often used to graphically illustrate data exchange standards and protocols. Frames appear in data books, communications standards, and instruction sets. For our purposes, a "frame" is defined as any element of a hierarchically structured data format. Frames are composed of sub-frames, which can themselves be de composed into further sub-frames. Ultimately, these sub-frames are composed of terminal frames which represent bit patterns, simple expressions, or value fields seen in a protocol. An example of a structured frame format is illustrated in FIG. 55.
FIG. 55 illustrates a frame comprising a sequence of three subframes. Each of the sub-frames can be further decomposed, perhaps into possible alternative sub-frames. The lowest level frames represent bit patterns. In the example, the second sub-frame is decomposed into two alternative sub-frames, one of which begins with the bit pattern "101 . . . " and the other which begins with "0 . . . ". Examples of typical industrial frame-based data formats include Asynchronous Transfer Mode (ATM) cells, Synchronous Optical Network (Sonet)/SDH frames, and the JPEG or MPEG stream data format. Additional frame-based protocols used in networking systems include Ethernet, FDDI, and token-ring.
Many designs simply process highly structured data such as, for example, a network switch. This structured data may conform to a "standard" at which different layers, or in which different modules, of a system communicate. The structure of the data may be an international standard, a standard in flux, or proprietary. In any case, in these designs, the structure of the data is an essential defining feature or parameter of the design.
Today, the design of a network interface chip typically progresses in four stages (see FIG. 56). In the first stage, the protocol is designed based on the structure of the data to be processed and the computations to be performed. This is done manually. After designing the protocol, an implementation of the protocol controller is undertaken by designing the Finite State Machine (FSM) implementing the required control logic. Again, this is usually performed manually. In the third stage, the designer translates the finite state machines into High-Level Description Language (HDL) code and integrates into the HDL code the computations required. At this point the designer can verify the design through simulation and perform synthesis of the design.
For the designer, translating from the protocol to the FSM's (stage 1 to stage 2) and from the FSM's to the HDL (stage 2 to stage 3) is a complicated and error-prone process. Graphical state machine entry systems can help in going from stages 2 to 3. However, this forces the designer to think about the design at more of an implementation level, i.e., in terms of states. This thought process can obscure the parameters of interest to the designer--the packets or cells or data frames to be processed. These FSM's are sensitive to the characteristics of the protocol; any change in the structure of the data often causes significant changes to the implementation of the design. For example a change such as adding a field or adding an alternative will force the re-design of the FSM's and potentially cause global changes to the HDL. If there is a bug in the design the designer is forced to debug at the HDL level, while the designer would like to understand, analyze, and debug the design at the protocol level.
The telecommunication designer needs a domain specific solution in the area of frame based protocols enabling him/her to work at the protocol level of abstraction.